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Performance  Examples 


The  IRS  system  -  finally 
started  to  use  in  2005 

•  5  years  of  delays 

•  costs  exploded  to  $2  B 

FBI  system  killed 

•  3  years  of  work 

•  $150  M 

•  5  CIOs,  9  program 
managers 

Britain’s  child-support  project 

•  a  year  late 

•  $844  M 

•  didn’t  pay  50%  of  cases 
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Transportation 

Automobiles 

•  Mercedes  Benz  -  batteries, 
windows,  temperature 

•  Bendix  Brakes 

•  Ford  Explorer 

Boeing  777 

•  Malaysian  Airlines 

•  Singapore 
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This  Is  No  Joke! 

These  are  not  new  problems. 

•  CONFIRM  system  20  years  ago 

•  Cancelled  after  3  14  years  and  $125  M 

How  long  will  society  tolerate  such  performance? 

Do  we  want  government  controls? 

•  Methods  standards  and  approval? 

•  Pre-shipment  reviews? 

•  Legislated  warranties? 

We  had  better  solve  our  own  problems  or  others  will  solve 
them  for  us. 
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Sir  Francis  Bacon 

“He  who  will  not  apply  new 
remedies  must  expect  new 
evils.” 
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Challenges  of  the  Future 

Our  priorities  must  change. 

Systems  are  now 

•  larger 

•  distributed 

•  integrated 

•  pervasive 

•  critical 

The  methods  of  the  past  are 
not  suitable  today. 

In  the  future,  they  could  be 
dangerous! 


f  WARNING  1 


CHALLENGES 

AHEAD 

V _ _ _ _ _ > 
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Systems  Development  Phases 

Phase  I  -  Feasibility 

•  afterWorld  War  II 

•  mid  1960s 

Phase  II  -  Manageability 

•  early  to  mid  1960s 

•  feasibility  had  much  lower  priority 

•  still  continuing 

Phase  III  -  Quality 

•  now 

•  manageability  will  be  lower  priority 

•  priorities:  safety,  security,  privacy,  usability,  etc. 
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Process  Criteria 

A  superior  process  must  meet  three  criteria. 

•  work  effectively  for  the  smallest  and  largest  programs 

•  consistently  produce  superior  results 

•  be  recognized  as  producing  superior  results 

The  current  generally-used  processes 

•  do  not  consistently  work  for  small  projects 

•  rarely  work  effectively  for  large  projects 

•  produce  inconsistent  and  often  poor-quality  results 
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Superior  Results 

A  superior  process  must  consistently 
deliver  products  on  schedule  and  for 
their  committed  costs. 

It  must  routinely  deliver  high-quality 
products. 

•  functions 

•  properties 

•  defects 

It  must  respond  to  changing  needs. 
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Systems  Problems  - 1 

Systems  have  emergent  properties. 

•  Emergent  properties  are  produced  by  synergies  among 
the  system’s  components. 

•  No  single  component  supplies  any  emergent  property. 

Example  emergent  properties 

•  performance 

•  reliability 

•  safety 

•  security 

•  usability 

•  maintainability 

•  installability 
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Systems  Problems  -  2 

The  quality  of  an  emergent  property  is  determined  by  the 

•  worst-quality  component 

•  lowest-performing  component 

•  least-reliable  component 

•  least  usable  component 

•  least  secure  component 

Therefore,  a  superior  process  must 

•  identify  all  poor-quality  components 

•  fix  all  poor-quality  components 

•  improve  all  poor-quality  components 

•  prevent  all  poor-quality  work 
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The  Scale-Up  Problem 

As  systems  become  larger 

•  they  become  more  complex 

•  their  development  is  more  challenging 

•  their  management  is  more  difficult 

•  new  problems  emerge  at  the  systems  level 

•  component  problems  are  magnified  at  higher  levels 

Therefore,  a  superior  process  must 

•  prevent  all  poor-quality  work 

•  guide  the  work  at  all  levels 
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Tolstoy:  Anna  Karenina 

“Happy  families  are  all  alike; 
every  unhappy  family  is 
unhappy  in  its  own  way.” 
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The  Common  Strategy 

The  most  common  strategy: 

•  If  it  isn’t  broken  -  don’t  fix  it. 

This  strategy  has  four  problems. 

•  Processes  break  in  an  infinite  number  of  ways. 

•  Fixing  one  problem  will  not  fix  the  next. 

•  These  random  fixes  do  not  fix  causes. 

•  The  process  is  not  consistently  or  measurably 
improved. 
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The  CMMI  Strategy 

The  only  effective  answer  is  a  strategy  that  is 

•  cohesive 

•  comprehensive 

•  based  on  sound  principles 

This  is  the  logic  for  CMMI. 

It  has  gaps. 

•  very  large  systems 

•  very  small  projects  and  organizations 
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Scalability 

Scalability  is  fundamental. 

Developers  now  typically 
use  the  same  practices  for 

•  a  1 ,000  LOC  application 

•  a  1 ,000  LOC  module  for 
a  1,000,000  system 

Examples  from  other  fields. 

•  boat  building 

•  building  construction 

•  accounting 
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Scalability  Requirements 

For  a  process  to  be  scalable,  every  key  aspect  must  scale 
up  and  down. 

•  practices 

•  measures 

•  quality  management 

Therefore,  the  work  at  every  level  must 

•  be  based  on  precise  and  detailed  plans 

•  produce  high-quality  products 

•  be  based  on  measured,  statistically  usable,  and 
auditable  data,  not 

-  after-the-fact  reports 

-  third-party  estimates 

-  guesses 
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Meeting  Schedules 


Fred  Brooks:  “Schedules 
slip  a  day  at  a  time.” 
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A  Process  Principle 

To  consistently  maintain  costs  and  schedules,  the  one-day 
slips  must  be  recovered  the  next  day.  If  not 

•  the  delays  will  compound 

•  the  commitments  will  become  unmanageable 

With  current  common  practices,  schedule  slips  cannot  be 
detected  until  projects  are  weeks  or  months  late. 

Then  it  is  generally  too  late  to  recover. 
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System  Schedules 

For  large-scale  integrated-systems-development 
programs 

•  Any  subsystem  delay  will  delay  the  system. 

•  Any  component  delay  will  delay  the  subsystem  and 
system. 

•  Any  project  delay  will  delay  the  component, 
subsystem,  and  system. 

•  Any  team  delay  will  delay  the  project,  component, 
subsystem,  and  system. 

•  Any  developer  delay  will  delay  the  team,  project, 
component,  subsystem,  and  system. 
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Program  Management 


To  manage  large  programs,  every 
system  level  must  be  managed. 

•  subsystems 

•  components 

•  projects 

•  teams 

•  developers 


Therefore,  to  consistently  produce  quality  products  on 
schedule  and  for  planned  costs,  every  developer  must 

•  consistently  produce  quality  products 

•  predictably  meet  schedules 
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Process  Requirements 

For  a  process  to  meet  these  needs,  it  must 

•  properly  manage  the  knowledge  work 

•  manage  costs  and  schedules 

•  manage  quality 


software 
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Knowledge  Work  - 1 

The  first  rule  for  managing  knowledge  work  is  to  recognize 
that  you  can’t  manage  it. 

The  knowledge  workers  must  manage  their  own  work. 

The  second  rule  for  managing  knowledge  work  is  that  the 
teams  and  developers  must 

•  know  how  to  manage  themselves 

•  negotiate  their  commitments  with  management 

•  manage  with  data 

•  own  their  own  work 
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Knowledge  Work 

To  manage  themselves, 
developers  must 

•  use  personal  processes 

•  follow  personal  plans 

•  measure,  track,  and 
report  status 

•  measure  and  manage 
quality 
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Balance  &  Refine 
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Knowledge  Work  -  3 

To  follow  a  defined,  planned,  measured,  and  quality- 
controlled  process,  developers  must 

•  work  on  self-directed  teams 

•  define  their  own  processes  and  plans 

•  negotiate  their  own  commitments 

•  be  competently  led  and  coached 
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Cost  and  Schedule 

There  is  no  secret  to  meeting  cost  and  schedule 
commitments. 

In  every  field,  only  four  things  are  required. 

•  The  developers  estimate  and  plan  their  own  work. 

•  Everyone  precisely  and  regularly  tracks  and  reports 
status  and  progress. 

•  Schedule  delays  are  addressed  every  day. 

•  When  requirements  change,  everyone 

-  revises  their  plans 

-  renegotiates  their  commitments 
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Quality  Management  - 1 

To  successfully  manage  quality,  the  development  process 
must  be  based  on  four  facts. 

•  The  longer  a  defect  remains  in  a  product,  the  more  it 
costs  to  find  and  fix  it. 

•  No  test  can  find  more  than  a  fraction  of  the  defects  in  a 
product. 

•  The  larger  and  more  complex  the  product,  the  smaller 
this  faction  will  be. 

•  To  get  a  high-quality  product  out  of  test,  you  must  put  a 
high-quality  product  into  test. 
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Quality  Management  -  2 

A  quality  process  must  strive  to  find  and  fix  all  defects 
before  test  entry. 

To  do  this,  the  process  must 

•  have  multiple  early  defect-removal  steps 

•  measure  product  quality  at  every  step 

•  measure  process  quality  at  every  step 

•  make  and  follow  personal  and  team  quality  plans 

•  regularly  track  product  and  process  quality 

•  use  testing  to 

-  verify  product  quality 

-  gather  quality  data 

•  promptly  correct  quality  deviations  from  plan 
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Conclusions 

These  principles  have  been  proven  with  CMMI  and  TSP 
and  are  being  piloted  for  systems  engineering  with  TSPI. 

The  critical  challenge  is  to  get  people  to  work  this  way. 

Consistently  superior  knowledge  work  must  include  the 
following  elements  -  at  all  levels. 

•  well-defined  and  consistently  practiced  principles  of 
personal  performance 

•  teambuilding  and  empowerment 

-  ownership  and  commitment 

-  leadership  and  coaching 

•  organizational  support  and  institutionalization 

•  quantitative  performance  measurement  and  appraisal 
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